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Abstract 

The Flight Dynamics Division (FDD) of the National Aeronautics and Space Administration (NASA) Goddard Space 
Flight Center (GSFC) provides extensive support and products for Space Shuttle missions, expendable launch 
vehicle launches, and routine on-orbit operations for a variety of spacecraft. A major challenge in providing support 
for these missions is defining and generating the products required for mission support and developing the method 
by which these products are exchanged between supporting agencies. As interagency and international 
cooperation has increased in the space community, the FDD customer base has grown and with it the number and 
variety of external interfaces and product definitions. Currently, the FDD has working interfaces with the NASA 
Space and Ground Networks, the Johnson Space Center, the White Sands Complex, the Jet Propulsion Laboratory 
(including the Deep Space Network), the United States Air Force, the Centre National d’Etudes Spatiales, the 
German Spaceflight Operations Center, the European Space Agency, and the National Space Development Agency 
of Japan). 

With the increasing spectrum of possible data product definitions and delivery methods, the FDD is using its 
extensive interagency experience to improve its support of established customers and to provide leadership in 
adapting/developing new interfaces. This paper describes the evolution of the interfaces between the FDD and its 
customers, discusses many of the joint activities with these customers, and summarizes key lessons learned that 
can be applied to current and future support. 


1 .0 Introduction 

In the early days of the space program, the interfaces between supporting elements were much simpler than they 
are today. As the feasibility of international space exploration and satellite communication was demonstrated, 
more countries and agencies joined the space community. Also, as missions progressed, other agencies were spun 
off from NASA, such as the Deep Space Network (DSN) and the Eastern Range (ER), and elements within NASA 
developed independent identities, such as the Flight Dynamics Facility (FDF) of the Goddard Space Flight Center 
(GSFC) Flight Dynamics Division (FDD). In the remainder of this paper, the term FDF is used to refer generically 
to the support functions of the GSFC FDD as performed in the FDF. 

The FDF currently provides both analytical and operational support for an average of seven Space Shuttle missions 
and ten expendable launch vehicle (ELV) launches each year. It also provides routine on-orbit support and 
products for a variety of operational spacecraft. A major challenge in providing support for these missions is 
defining and generating the products required for mission support and developing the method by which these 
products are exchanged between supporting agencies. 

Since its inception, the FDF has developed a large number of products for support of an increasing number of 
interfaces with customers both inside and outside the GSFC community. The types of products and services that 
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the FDF provides for spacecraft launches and Shuttle mission support are discussed in this paper. In addition, the 
paper chronicles the FDF experience with interagency and international interfaces and joint activities for mission 
support as they have evolved through the years. The paper also discusses a number of the lessons learned during 
this evolution. For more detailed information on FDF support services to its customers, see Reference 1, which can 
be accessed on the Internet at “http://fdd.gsfc. nasa.gov/FDD_EOY95. html”. 

Section 2 of this paper discusses the FDF products and services, and Section 3 provides details of the major FDF 
interfaces and activities with key centers and agencies. Section 4 gives a summary of the key lessons learned 
during the evolutionary process. 

2.0 FDF Products and Services 

On April 12, 1996, NASA celebrated the 15 th anniversary of the launch of the first Space Shuttle mission, Space 
Transportation System-1 (STS-1). In the early days of the Shuttle program, every day seemed to bring a new 
customer with a new requirement. FDF customers were no longer limited to the GSFC community. To meet the 
commitments required to support the Shuttle program, the FDF established new relationships with other NASA 
centers and agencies within the Department of Defense (DOD). On many occasions, new products and methods of 
delivery were identified, developed, tested, and implemented before the official paperwork was received. However, 
those early days provided a solid foundation for the changes, in both product and customer, that were to take place 
over the next 15 years. Table 1 shows the chronology and extent of the growth in FDF customer support that has 
taken place since 1978. More specifically, the significant growth in Shuttle product and customer support between 
1981 and 1996 is illustrated in Figure 1. 

3.0 Interfaces and Activities 

In addition to exchanging products with other centers and agencies, the FDF has engaged in a large number of 
joint activities with these organizations in the area of flight dynamics. This section describes the major interfaces 
that the FDF has with external organizations and discusses some of the joint activities the FDF has performed with 
these organizations. Figure 2 illustrates these major interfaces. In this figure, the home agency and the section 
number of this paper that describes the FDF interface with the organization is indicated in each box. 

3 . 1 Johnson Space Center (JSC) 

The FDF has participated in a number of joint activities with several different government and contractor support 
groups within the Flight Dynamics Design Division (FDDD) at the Johnson Space Center (JSC) in support of the 
Shuttle program, including Ground Navigation, the Flight Dynamics Officers, the Instrumentation and 
Communications Officers (INCOs), Houston Track (which handles flight-dynamics-related communications with 
external elements) and the Ascent/Descent group. In the remainder of this section, the term JSC will refer 
generically to the JSC FDDD. 

The FDF/JSC joint activities have included the following: 

• Verification of the consistency of the orbit determination and orbit propagation software and astrodynamic 
constants used at JSC and at the FDF 

• Navigation certification efforts to certify the validity of Shuttle orbit determination based on Tracking and 
Data Relay Satellite (TDRS) System (TDRSS) tracking data 

• Ongoing verification of FDF-generated Shuttle orbit determination solutions for Emergency Mission 
Control Center (EMCC) support 

• Efforts to maintain consistency in implementation of the mean equator and equinox of J2000.0 coordinate 
system 

• Ongoing efforts to maintain a consistent set of tracking station geodetics 

• Ongoing verification of new tracking data capabilities, such as the Doppler-compensation-enabled 
capability at the White Sands Complex (WSC) 
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Table 1 . Growth in FDF Customers Outside the GSFC Community 


Customer/Milestone 

Starting 

Date 

New 

Customer 

New 

Product(s) 

Space Shuttle support requirements 

1978 

V 

Y 

Ariane support requirement [Centre National d’Etudes Spatiales (CNES), 
the French Space Agency] — Provide launch support for ail launches 

1981 

Y 

N 

University of Arizona requirement for Space Transportation System (STS) 

1982 

Y 

N 

Ames Research Center— STS 

1983 

Y 

N 

Langley Research Center (LaRC) for STS 

1982 

Y 

Y 

Tracking and Data Relay Satellite (TDRS) System (TDRSS) support 
requirements 

1983 

Y 

Y 

Naval Research Laboratory (NRL) for STS 

1984 

Y 

N 

North American Aerospace Defense Command (NORAD) support 
requirements 

1985 

Y 

N 

Centaur G' support requirements — Lewis Research Center (LeRC) 

1985 

Y 

Y 

Network Consolidation Plan — Canberra, Goldstone, and Madrid transferred 
to Jet Propulsion Laboratory (JPL) 

1985 

Y 

N 

CNES Systeme Probatorie d’Observation de la Terre-1 (SPOT-1) 
spacecraft support (first of many) 

1986 

Y 

N 

Privatization of the Delta launch vehicle 

1988 

Y 

Y 

Ariane support requirement change (CNES) — Provide launch support for 
only northerly launches 

1989 

N 

N 

Launch procedures for Shuttle rendezvous missions 

1990 

N 

N 

Marshall Space Flight Center (MSFC) — STS payload 

1990 

Y 

Y 

Pegasus support requirement — Provide launch support for NASA missions 

1991 

Y 

N 

Ocean Topography Experiment (TOPEX) spacecraft support 

1992 

Y 

Y 

Long Duration Balloon Program 

1993 

Y 

N 

National Oceanic and Atmospheric Administration (NOAA) — New tracking 
data interface 

1994 

N 

N 

United States Space Command (USSPACECOM) tracking data in NORAD 
B3 format 

1994 

MM 

Y 

White Sands Complex (WSC) stationary vectors with velocity 

1995 

Y 

Y 

Express spacecraft support — German Space Operations Center (GSOC) 

1995 

Y 

N 

Titan support requirement (USAF) — TDRSS supporting launch 

1995 

Y 

N 

National Space Development Agency of Japan (NASD A) — Engineering Test 
Satellite VI (ETS-VI)AJpper Atmospheric Research Satellite (UARS) 
experiment (1995) 

1995 

Y 

N 

Atlas/Centaur support requirement returns — TDRSS supporting Atlas 
Centaur 

1996 

Y 

N 

NASDA — Tropical Rainfall Measuring Mission (TRMM)/ Communication and 
Broadcasting Engineering Test Satellite (COMETS) 

1998 

N 

Y 
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Figure 1. FDF Shuttle Product and Customer Growth Comparison: 1981 and 1996 
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Figure 2. Major FDF Interfaces With External Organizations for 
Launch and Shuttle Support 
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Most of these joint activities have been performed under the umbrella of the TDRSS Orbit Determination and 
Navigation Working Group (TODNWG). The TODNWG is an intercenter working group that was established to 
address operational and technical problems associated with TDRSS navigation and to provide a forum for technical 
interchange between JSC and GSFC. This working group is composed of technical personnel from the JSC 
Navigation Integration Office and from the GSFC FDD and their respective contractors — Computer Sciences 
Corporation (CSC/GSFC), AlliedSignal (ATSC/GSFC and JSC), and Rockwell Space Operations Company 
(RSOC/JSC). This group began meeting in 1982 to develop a STS/TDRSS Navigation Certification Plan 
(Reference 2) and to carry out preliminary software testing and verification between the two centers. 

The major early TODNWG goal was the certification of TDRSS for Shuttle navigation support. The first step in 
this process was verifying the consistency of the orbit determination and orbit propagation software and 
astrodynamic constants used at JSC and at the FDF. JSC and the FDF performed parallel orbit determination and 
orbit propagation runs and then compared the results. From August 1983 (the beginning of TDRSS tracking 
services) to October 1984 (the end of the STS-41G mission), the TODNWG members discussed and analyzed the 
results of Shuttle tracking tests during the STS-41C and STS-41G missions and successfully completed the 
augmented single-TDRS (TDRS-East plus ground stations outside the TDRS-East coverage) certification effort 
(Reference 3). Following the launch and on-orbit checkout of the second TDRS, the next step in the certification 
process was a successful joint JSC/GSFC two-TDRS certification effort to certify the TDRS EastTDRS-West 
configuration (without ground station augmentation) for nominal on-orbit navigation support of Shuttle flights 
(Reference 4). The two-TDRS certification missions were STS-29 and STS-30 (nonrendezvous missions) and 
STS-32 (a rendezvous mission). 

A consistent set of tracking station geodetics has been maintained at JSC and the FDF through joint TODNWG 
efforts. The World Geodetic System 1984 (WGS 84) geodetic reference system (Reference 5) is the current 
baseline system for the catalog of tracking station geodetic locations maintained by the FDF and documented in 
Reference 6. However, both JSC and the the FDF currently use the Spaceflight Tracking and Data Network 1973 
(STDN 73) geodetic reference system in their orbit determination and orbit propagation software. Consequently, 
the FDF WSG 84 geodetic database must be transformed to the STDN 73 system before use. The converted FDF 
locations are periodically compared with the JSC values to ensure consistency. 

Another TODNWG activity was coordinating the implementation of the mean equator and equinox of J2000.0 
coordinate system at JSC and at the FDF, including the algorithms for converting to and from the previous 
standard coordinate system, which was the mean equator and equinox of B 1950.0 system. The algorithms used for 
these conversions at JSC and at the FDF were exchanged and discussed, and it was agreed that they were 
consistent to within acceptable tolerances. The final step in this process was an electronic interface test in which 
J2000.0 state vectors in the form of improved interrange vectors (IIRVs) were successively generated and 
transmitted from the JSC mission operations computer (MOC) to the FDF and from the FDF to the JSC MOC. 

During each Shuttle mission, routine Shuttle orbit determination is performed by the JSC Ground Navigation 
group. Houston Track transmits hourly Shuttle state vectors based on these solutions and, when appropriate, on- 
orbit maneuver sequences to the FDF. These vectors are then processed by the FDF to generate Space and Ground 
Network acquisition data. Houston Track also keeps the FDF informed of any important developments in Shuttle 
support. The FDF, in turn, provides Houston Track with daily TDRS state vectors for use by JSC Ground 
Navigation in performing Shuttle orbit determination with TDRSS tracking data. 

In the event that an EMCC situation occurs during a Shuttle flight, the JSC Mission Control Center (MCC) 
function will be transferred to the Kennedy Space Center (KSC). A JSC flight control team and their support 
computer will fly from JSC to KSC and continue Orbiter support from there until the JSC MCC is in operation 
again or until the Shuttle lands. Because the EMCC computer does not have an orbit determination capability, the 
Shuttle orbit determination function will be assumed by the FDF, and the FDF will provide acquisition data 
directly to the Space and Ground Networks, as well as to the flight control team at KSC. To verify the FDF 
capability to provide orbit determination support for a Shuttle EMCC, joint JSC/GSFC EMCC exercises are 
performed at approximately 6-month intervals during actual Shuttle flights. The FDF performs Shuttle orbit 
determination using the software and modeling that would be used during an actual EMCC support, and the 
resulting solutions are transmitted electronically and via facsimile from the FDF to the JSC Ground Navigation 
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group. (In an actual EMCC situation, the solutions would be transmitted via facsimile to the JSC flight support 
team at KSC for manual entry into the EMCC support computer.) These solutions are then compared with the 
corresponding solutions obtained by the JSC Ground Navigation group to ensure that the FDF solutions are within 
allowable tolerances, especially for deorbit burn support. EMCC exercises were performed during the STS-47, 
STS-64, STS-67, and STS-74 missions. 

The most recent joint activity has been to verify the new White Sands Complex (WSC) Doppler-compensation- 
enabled capability to generate valid Doppler tracking data during periods when forward-link Doppler 
compensation is enabled. This new capability makes it possible to maintain solid TDRSS acquisition of a 
spacecraft and to obtain valid Doppler tracking data at the same time. Tests of the new capability have been 
performed with TDRSS user spacecraft (Reference 7) and during the STS-74, STS-75, and STS-76 missions. The 
STS-76 mission was the formal verification mission for the new Doppler-compensation-enabled capability. 

The interactions with the JSC INCOs have been primarily concerned with maintaining communications with the 
Orbiter during any type of spacecraft contingency, such as a return to launch site (RTLS), transoceanic abort 
landing (TAL), or abort-once-around (AOA). The FDF Space Network (SN) acquisition data for contingency 
support is usually based on trajectory tapes and/or hardcopy data provided by the JSC ascent/descent group. For 
most contingency cases, the acquisition data are sufficiently accurate to maintain good communications with the 
Orbiter. However, in the event of a ditch contingency or an EMCC end-of-mission landing, only minimal 
trajectory information will be available from JSC, and this has been a matter of great concern in the past. 
However, with the advent of the new Second TDRSS Ground Terminal (STGT), FDF personnel recognized that a 
modification to the STGT vector processing algorithms would greatly enhance the accuracy of the acquisition data 
for these particular contingencies. The modification recommended by the FDF has been implemented at WSC, 
which now makes it possible to provide good TDRS acquisition data for both ditch cases and EMCC landings. 

The JSC Ascent/Descent group is responsible for providing users with premission Shuttle trajectory data covering 
the nominal launch and all possible launch contingencies. In the past, this has meant the transfer of several 
trajectory data tapes, called D-tapes, for each Shuttle mission (Reference 8). For some time, JSC and FDF 
personnel have been investigating better ways of transferring the trajectory data and methods for reducing the 
number of tapes required for each mission. In support of this effort, the FDF acquisition data group has built up a 
large library of D-tapes, which are now available for use as generic D-tapes where appropriate. The first step in 
the direction of using generic D-tapes for mission support was the designation of D-tapes for RTLS, TAL, and 
AOA landings as generic, i.e., it is no longer necessary for JSC to provide mission-specific D-tapes for these 
contingency cases. A joint analysis of the D-tape requirements for nominal launches is nearing completion; the 
results are expected to support extensive use of generic, rather than mission-specific, D-tapes for nominal launch 
support. This is particularly important for rendezvous missions, which typically require up to five D-tapes to cover 
the ascent variations across the launch window (Reference 9). 

3.2 White Sands Complex (WSC) 

The FDF has maintained a strong interface with the White Sands Complex, beginning with the original White 
Sands Ground Terminal (WSGT) and continuing with the new STGT and the White Sands Ground Terminal 
Upgrade (WSGTU). The early WSGT interface was through the White Sands/NASA Interface Working Group 
(WNIWG). The early focus of the joint activities between the FDF and WSC was in the areas of TDRS orbit 
determination, TDRSS tracking data quality, and user state vector processing, especially for Shuttle support. 

Initially, WSGT performed their own TDRS orbit determination, based on single-station tracking data from the 
Tracking, Telemetry, and Command (TT&C) System, for TDRSS user and stationkeeping support. The FDF, on 
the other hand, required more accurate TDRS orbit determination for processing TDRSS tracking data for user 
orbit determination. The FDF TDRS solutions were based on multistation (bilateration) tracking using the 
Bilateration Ranging Tracking System (BRTS) (Reference 10). Typically, tracking data from a White Sands BRTS 
transponder were combined with tracking data from an Ascension Island, American Samoa, or Alice Springs, 
Australia, BRTS transponder. In 1986, a joint WSGT/FDF TDRS Orbit Determination Working Group (TOWG) 
was formed to consider the feasibility of using the more accurate FDF BRTS-based TDRS orbit solutions for 
TDRSS user support at WSGT. As a result of this effort, the FDF TDRS solutions based on BRTS tracking have 
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been used at WSGT/WSC since April 1987. The FDF also provides quick-turnaround (4-hour) TORS orbit 
solutions based on intensive BRTS tracking to WSC following each TORS stationkeeping maneuver. These 4-hour 
solutions are also provided to JSC whenever a Shuttle mission is in progress at the time of the TORS 
stationkeeping maneuver because high-accuracy TORS solutions are required for Shuttle orbit determination. 

A continuing joint activity between the FDF and WSC has been the coordination and verification of 
solar/lunar/planetary ephemeris (SLP) files, geopotential files, and astrophysical constants used in the FDF and 
WSC software. A major joint effort was carried out in 1984 to verify that the Goddard Earth Model-9 (GEM-9) 
geopotential was properly implemented at WSGT. In 1990, the FDF provided the STGT Project with an SLP file 
in VAX format for use at STGT, and a series of orbit propagation tests was performed to verify the STGT 
modeling and propagation software. These tests gave excellent results, with propagation differences in the 
submeter range (Reference 11). To maintain consistency in TORS maneuver planning and execution, the FDF 
uses the same SLP file that was provided to STGT when processing STGT-generated TORS state vectors. This 
avoids the necessity of continually updating the UT1-UTC* values used at WSC to maintain consistency with the 
FDF values. Since the time of this original calibration, the FDF has updated its geopotential field twice, first to the 
GEM-T3 model and then to the Joint Gravity Model-2 (JGM-2) model. In addition, the FDF recently provided 
STGT with an updated SLP file and performed propagation tests to verify the STGT installation of this SLP file 
and implementation of the JGM-2 geopotential. 

A very important joint activity is in the area of testing and improving the state vector processing algorithms at 
WSC, particularly with regard to the processing of launch, on-orbit, and landing maneuver sequences, which allow 
the TORS antennas to accurately follow powered flight and reentry trajectories. The specific algorithms for 
processing so-called “stationary” vectors is also important, because these vectors are used extensively by the FDF to 
support Shuttle and Expendable Launch Vehicle (ELV) launches and to generate backup support for Shuttle 
contingency trajectories in case there is a problem with the transmission or processing of maneuver sequences. 
The FDF, the GSFC Network Control Center (NCC), and WSC conduct exhaustive vector processing tests for new 
vector processing capabilities, and a mission-specific vector verification test is performed before each Shuttle 
mission to verify the readiness of WSC to support all acquisition data support requirements for the flight. As 
discussed in Section 3.1, these tests often lead to recommended improvements in the vector processing capabilities 
at WSC. 

3.3 Jet Propulsion Laboratory (JPL) 

The FDF interface with the Jet Propulsion Laboratory (JPL) became more extensive when the Deep Space Network 
(DSN) was implemented under JPL. The DSN includes antenna sites at Canberra, Australia; Madrid, Spain; and 
Goldstone, California. These sites are frequently scheduled for Shuttle and ELV launch support. The FDF 
provides acquisition data and tracking data evaluation for the DSN sites. The interface for acquisition data is to 
transmit the data via high-speed lines to JPL. JPL then forwards the data to the individual sites. The FDF also 
maintains a low-speed interface directly with the sites. The high-speed transmission format is currently limited to 
vector transmissions such as IIRVs and Extended-Precision Vectors (EPVs) (Reference 12). For launch support, 
single vectors are insufficient for support, and antenna pointing angles are provided directly to the sites via low- 
speed lines from the FDF. 

3.4 Department of Defense (DOD) Eastern Range/Western Range (ERAVR) 

For most Shuttle and ELV launches, the FDF provides acquisition data to the DOD for stations at either the 
Eastern or Western Range. The DOD also has the capability of transmitting data to these sites. In this unique 
situation, the FDF and DOD have the capability of providing backup support to each other. In other situations, the 
FDF and the DOD have had to develop procedures to ensure that they do not override each other’s data. 

For Shuttle missions, the FDF is the prime provider of data for the Orbiter, and the DOD is the prime provider for 
any deployed payloads. If the FDF were unable to satisfy the acquisition data requirement, the DOD would be 


* UTC = coordinated universal time; UT1 = universal time corrected for polar motion 
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called up to provide that function. If the DOD were unable to provide acquisition data for a deployed satellite, then 
the FDF would be requested to provide the support. 

With the increasing number of satellite launches, the FDF and DOD have had to work closely to coordinate 
overlapping activities, such as an ELV launch during a Shuttle mission. 

3.5 5 th Space Operations Squadron (5 SOPSf 

The FDF provides acquisition data support to the Air Force Satellite Control Network (AFSCN) Remote Tracking 
Stations (RTSs) for Shuttle and ELV missions. The acquisition data are provided to the RTSs through 5 SOPS at 
the Onizuka Air Station (OAS) in Sunnyvale, California. 

For Shuttle missions, the FDF provides premission acquisition data to 5 SOPS for the RTS sites approximately 
7 days before the scheduled launch day. After launch, the FDF provides 5 SOPS with regular updates for the RTSs 
as defined in STS requirements. Because of the FDF’s indirect interface with the RTS, a 15- to 30-minute delay 
can be expected between the FDF and the sites. Additional procedures have been developed in the cases where 
real-time updates may not be possible in time. 

ELV support is mission dependent, but it usually includes providing 5 SOPS with premission marked event vectors 
(i.e., cut-off and injection vectors) for RTS acquisition. Updated information is provided to 5 SOPS for RTSs in 
near real time. The deliveries for ELV support are usually done via facsimile. 

Within the past year, the FDF has had the opportunity to support Titan/Centaur missions using the SN. For Titan 
support, the FDF has been working with 5 SOPS to develop a high-speed transmission interface for the FDF to 
receive updated launch information from 5 SOPS. The high-speed interface and the SN support of launches has 
been successfully implemented and demonstrated during the last several Titan missions. Because of the success of 
this interface, a similar high-speed interface with the ER will be used for SN support of Atlas/Centaur launches. 

3.6 National Oceanic and Atmospheric Administration (NOAA) 

The FDF has supported the National Oceanic and Atmospheric Administration (NOAA) for both the Geostationary 
Operational Environmental Satellite (GOES) and NOAA satellite series. For both of these series, the FDF 
provides acquisition data to the Ground Network after spacecraft injection. However, for the GOES satellites, the 
FDF support is more extensive and includes providing attitude and orbit determination support to the GOES 
Satellite Operations Control Center (SOCC) during the early mission phase. For the NOAA satellites, the FDF’s 
primary requirement has been to provide accurate acquisition data to the Ground Network. 

For all NOAA satellites, the FDF has a requirement to provide acquisition data support for the First 3 weeks of the 
mission. This requirement was developed based on the experience that 3 weeks was the appropriate amount of 
time to define a stable orbit for the satellite and to transition to the standard NOAA satellite tracking schedule. 
During the launch support phase, the FDF receives a number of data sources for initial orbit determination, such as 
(1) an injection vector from the NOAA Automated Ground Equipment (NAGE) and the General Electric Real- 
Time System (GERTS), (2) data from the Launch Trajectory Acquisition System (LTAS), and (3) North American 
Aerospace Defense Command (NORAD) elements provided by the United States Space Command 
(USSPACECOM). Of the data sources, the NORAD elements were identified as the most accurate. The FDF was 
able to use the NORAD elements in orbit determination solutions to determine short predictions (approximately 48 
hours) of the satellite orbit. The FDF requires up to 2 weeks of NORAD elements before the orbit determination 
predictions are accurate for longer periods (up to 1 week). 

For the NOAA-J mission, the FDF performed premission analysis and determined that the FDF would be able to 
provide orbit determination that converged to a stable orbit in a much shorter period of time if C-band tracking 
data were made available to the FDF. The FDF did receive the C-band tracking data and was able to define a 
stable orbit within 10 hours after launch. As a result, NOAA had a better initial orbit definition, and the FDF 
required less frequent acquisition data updates. 


* Previously the 750 th Space Group (750 SGP) and before that the Consolidated Space Test Center (CSTC). 
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3.7 Centre National d’Etudes Spatiales (ONES) 

As discussed in Section 2, the FDF has provided varying levels of support to Centre National d’Etudes Spatiales 
(CNES) through the years. The involvement with CNES was initiated with the NASA support of Ariane launches 
in 1981 . The FDF participated in a series of working group meetings with CNES personnel to define the interface. 
For the Ariane launches in the 1980s, the FDF provided acquisition data support to the NASA Ground Network 
stations and provided early orbit estimation to CNES. The acquisition data and estimation were based on LTAS 
data from both NASA and CNFS Ground Network s’tes. 

The support increased to include early orbit support for the SPOT missions. The SPOT missions required an 
understanding of the changing launch trajectory through the launch window and close coordination with CNES for 
the appropriate trajectory selection during launch. The FDF early launch support was critical to ensuring first pass 
acquisition at the Fairbanks, Alaska, station. The support for the SPOT mission set a precedent for cooperation for 
subsequent missions such as TOPEX and Helios. 

Recently, the FDF has been working with CNES in utilizing CNES Ground Network resources for NASA 
launches. The latest cooperation was for Kerguelen Station tracking of the Delta/Polar launch on February 24, 
1996. The Kerguelen station was instrumental in providing verification of the spacecraft orbit injection. 

3.8 National Space Development Agency of Japan (NASD A) 

Recently, the FDF has been sharing its expertise in SN orbit determination and spacecraft acquisition with the 
National Space Development Agency of Japan (NASDA). NASDA is currently developing a tracking and data 
relay satellite system, and it has worked with the FDF to develop interfaces to facilitate system validation and 
future interoperability. Specifically, NASDA plans to accomplish the following: 

• Validate forward-link commanding from NASDA’ s tracking and relay satellite to a user spacecraft 

• Validate receipt of return-link telemetry from the user spacecraft at the spacecraft’s operations control 
center 

• Validate the orbit solutions obtained from tracking the user spacecraft from NASDA’s tracking and relay 
satellite 

The first two objectives were successfully demonstrated during tests conducted between NASDA’s Engineering 
Test Satellite (ETS)-VI and NASA’s Upper Atmospheric Research Satellite (UARS) in June and July of 1995. 
Tests to accomplish the latter objective are planned to occur in 1998 between NASDA’s Communication and 
Broadcasting Engineering Test Satellite (COMETS) and the Tropical Rainfall Measuring Mission (TRMM) 
satellite, a joint project between NASA and NASDA. 

To achieve these objectives, agreement was needed on the following interfaces: 

• Format and media for state vector exchange 

• Format and media for tracking data exchange 

• Source and update times of environmental data and values of physical constants 

In addition, the propagation models needed to be examined and understood to ensure meaningful results when 
comparing orbit determination solutions. 

Negotiating the new interfaces revealed two minor problems. First, NASDA’s tracking data format was 
incompatible with any existing NASA format, and other priorities precluded modifying the FDF’s tracking data 
processing software to accept the NASDA format. Consequently, NASA will not be able to use NASDA tracking 
data in the near future. Secondly, the FDF preferred to exchange vectors in a rotating Earth-fixed coordinate 
system, whereas NASDA wished to use the geocentric true of date (GTOD) coordinate frame. Use of the GTOD 
frame introduces the potential for increased error resulting from inconsistencies in UT1-UTC information in 
environmental data files. Coordinating file updates with external centers is not practical because the FDF 
frequently must freeze its configuration due to mission support requirements. As a result, in the future both 
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agencies need to be aware of updates to the UT1-UTC data and its impact on state vector exchange and 
propagation. 

A valuable lesson learned from these experiences was that a thorough understanding of the processes behind 
interfaces, together with good communications between the groups involved, can help achieve early recognition of 
potential interface problems. This makes it possible to develop a problem resolution or workaround or can 
minimize problems further down the line that will be more costly to resolve. 

3.9 Other International Agencies 

The FDF has also developed mission support interfaces with other international agencies: 

• European Space Operations Center (ESOC). For the Earth Resources Satellite (ERS) mission launched 
onboard an Ariane, the FDF coordinated support with ESOC for early orbit support. 

• German Space Operations Center (GSOC). The FDF has also developed a support interface with GSOC. 
For the Experiment Reentry Space System (EXPRESS) mission, the FDF worked with GSOC to develop an 
electronic high-speed interface for vector exchange. The interface developed for Express mission support 
was also used for the recent Radarsat launch support. 

• Russian Space Agency. FDF involvement with the Russian Space Agency started with support of the 
Apollo/Soyuz Mission in 1975. More recently, the FDF interfaced with the Russian Space Agency in the 
preparations for and the launch of the Total Ozone Mapping Spectrometer (TOMS) instrument onboard the 
Soviet Meteor-3 satellite in August 1991. For this mission, the FDF received vectors from the Soviet 
Central Aerological Observatory (CAO) and was able to coordinate with Soviet flight dynamics specialists 
to compare and coordinate vector propagation modeling techniques (Reference 13). Now in the age of the 
international space station, the FDF is supporting communication with the Russian space station Mir by 
providing acquisition data to the Wallops and Dryden stations. 

4.0 Summary 

As the FDF interfaces with external elements evolved over the years, a number of lessons were learned that will be 
useful in developing new interfaces in the future. These lessons include the following: 

• It is important to establish common, well-defined interfaces and processes from the beginning. 

• The number of common parameters that must be maintained between elements should be held to a 
minimum consistent with meeting all support requirements. 

• Error-prone elements and processes should be eliminated wherever possible. For example, use of a rotating, 
Earth-fixed coordinate system (instead of an inertial system) when exchanging state vectors between centers 
eliminates the potential for errors resulting from inconsistencies in the values of UT1-UTC used at the two 
centers. 

• It is important to thoroughly understand the processes underlying each interface. For example, an in-depth 
understanding of the vector processing algorithms used at STGT enabled FDF personnel to recommend an 
enhancement to these algorithms that significantly improved the accuracy of SN acquisition data for certain 
Shuttle contingency cases. 

• Flexibility and adaptability must be maintained in all interfaces. The requirements and customers for any 
given interface are constantly evolving. 

• Interoperability — the cooperative cross-support between agencies involving the use of the data relay 
satellites of one agency to support users of the data relay services of the other agency — should be 
encouraged. 

• Open communication between individuals in different organizations is very helpful in resolving any 
interface problems that may arise. 
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• Those responsible for developing and maintaining interfaces must be kept informed of all activities and 
agreements related to the interfaces. 

• Feedback from the interface process is vital in the design and building of new hardware and software 
systems. 

Application of these lessons has resulted in external interfaces that are manageable and robust, allowing the FDF 

to support an increasing numbers of customers. 

The FDF’s interfaces continue to evolve. The FDF and its customers are moving into new technologies that permit 

more flexible interfaces. As established interfaces are adapted to these new technologies and new interfaces are 

developed, it becomes increasingly important to apply the lessons learned from the earlier development efforts. 
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